IBIS Macromodel Task Group

Meeting date: 13 February 2024

Members (asterisk for those attending):
Achronix Semiconductor:       Hansel Dsilva
Amazon:                       John Yan
ANSYS:                      * Curtis Clark
                            * Wei-hsing Huang
Aurora System:              * Dian Yang
                              Raj Raghuram
Cadence Design Systems:     * Ambrish Varma
                              Jared James
Dassault Systemes:            Longfei Bai                             
Google:                       Hanfeng Wang
                              GaWon Kim
Intel:                      * Michael Mirmak
                              Kinger Cai
                              Chi-te Chen
                              Liwei Zhao
                              Alaeddin Aydiner
Keysight Technologies:        Fangyi Rao
                              Majid Ahadi Dolatsara
                              Stephen Slater
                              Ming Yan
                              Rui Yang
Marvell:                      Steve Parker
Mathworks (SiSoft):           Walter Katz
                              Graham Kus
Micron Technology:            Justin Butterfield
Missouri S&T:                 Chulsoon Hwang
                              Yifan Ding
                              Zhiping Yang
Rivos:                        Yansheng Wang
SAE ITC:                      Michael McNair
Siemens EDA (Mentor):       * Arpad Muranyi
                            * Randy Wolff
Teraspeed Labs:               Bob Ross
Zuken USA:                  * Lance Wang

The meeting was led by Arpad Muranyi.  Curtis Clark took the minutes.

--------------------------------------------------------------------------------
Opens:

- None.
  
-------------
Review of ARs:

Michael: Develop a new clarification BIRD to more clearly define relationships
         between concepts, terms, and parameters such as block, block size,
         wave_size, etc.
         - Done.  Michael sent draft1 to the ATM list just prior to the meeting.
         
Michael: Send draft3 of BIRD229.1 to the ATM list.
         - Done.  Michael sent draft3 to the ATM list on February 6, 2024.

--------------------------
Call for patent disclosure:

- None.

-------------------------
Review of Meeting Minutes:

Arpad asked for any comments or corrections to the minutes of the February 6th
meeting.  Michael moved to approve the minutes.  Dian seconded the motion.
There were no objections.

--------------
New Discussion:

BIRD229.1 draft3:
Michael shared BIRD229.1 draft3 and reviewed the changes it contains, including:
- Minor editorial and formatting changes
- Corrected several instances of a case related typo in a value of the Type
  subparameter: Time_Domain -> Time_domain
- AMI_output_parameters_file was changed from optional to required, per the
  discussion at the February 6th meeting.  Michael reiterated the reason for
  the change.  This BIRD is being relied upon to provide the information that
  allows the parser to address BUG227.  The root name checking requested in
  BUG227 would not be possible if AMI_output_parameters_file were not provided.
  
Michael noted a new explicit statement in the AMI_output_parameters_file
description:
  "in the absence of Out or InOut parameters, the file contents would consist
   only of the root name"
Ambrish asked for confirmation that this statement is consistent with IBIS 7.2.
Michael confirmed that it is.  He noted that if an AMI executable model has no
Out or InOut parameters to return, then it is still obligated to return the
root name in parenthesis as the contents of AMI_parameters_out.

Arpad said that this draft looked good in terms of describing Michael's original
plan for providing this information.  However, he said he had two remaining
questions: how to the handle the precision of the results comparisons, and
what about Walter's proposal to put this information in the .ami file instead
of the .ibs file?

Arpad recalled that Michael had asked how Walter's proposal would replace the
loss of the Executable_index and Direction subparameters.  Michael had said he
could envision ways in which the information provided by Executable_index could
be added to the .ami file, but we would have to provide more information in the
.ami file and might need to have a different .ami file for each of the different
builds of the same .dll/.so.  Arpad said he had thought about this issue, and he
didn't think we would need multiple .ami files.  He said we might use a Reserved
parameter of type Table or List to refer to multiple sets of test data.

Michael said that unless anyone sees a way in which we would be limiting
ourselves with the existing proposal, he would prefer to keep the existing
proposal and place the information in the .ibs file.  He acknowledged that this
BIRD is strictly focused on comparing the results of AMI processing, but he said
this is because we have intentionally sidestepped issues like channel definition
and channel measurement comparisons.  We will eventually have to enhance the
[Test Load] and [Test Data] keywords to properly support the AMI context, and
these keywords exist in the .ibs file.

Ambrish said that he preferred Michael's approach and thought we should put this
information in the .ibs file.  He said this BIRD is really testing the [Model],
and he thought it made sense to have the test configuration and results
information at the [Model] level instead of inside the .ami file.  Arpad said
he had raised the question only to make sure that we reviewed the options.  He
wanted to make sure we were not sticking with the existing proposal only for the
sake of expediency.

Arpad asked about the precision of the results comparisons.  He said that if the
goal of providing multiple sets of results is to capture minor numerical
differences between OSs and architectures, the ASCII format results files will
not be sufficient.  He asked whether Michael was considering a binary format for
the results files.  Michael said that allowing a binary format file would not
cause as many issues for him as putting the data in the .ami file would have.
However, he noted that he was expecting the results comparisons to be
informative, and he was not proposing red-flag type failures over a difference
in the 15th decimal place.  He said that it was really up to the user
configuring the EDA tool to decide how many decimal places were considered when
comparing to the golden results.  He said that this BIRD is concerned first and
foremost with detecting first-order errors, for example, a model not properly
parsing a parameters string sent to it by a particular tool.  Michael said that
even if the ASCII format results files limit the ability to detect minor
numerical differences, the Executable_index still has value.  It documents the
OS and architecture variants for which the model maker has provided formal test
results.  He said that ideally the model maker should provide an
Executable_index entry for each line provided in their [Algorithmic Model]
keyword, and he would like to encourage that behavior.

Michael said that the goal of this BIRD is to allow model makers and tool
vendors to find issues with their own and each other's work as early as
possible.  Michael moved to submit this version (draft3) to the Open Forum
as BIRD229.1.  Lance seconded.  There were no objections.

Block, "block size", wave_size clarification BIRD:
Michael said he had reviewed the language used in IBIS 7.2.  He said the goal of
this proposal would be to address any possible confusion for readers who might
have gotten the impression that "block_size" (which is never actually used in
the text) is some alternate to wave_size.

Michael reviewed the draft1 he had sent out.  He said that the only five places
in IBIS 7.2 that talk about a "block" in ambiguous terms are in the BCI
parameters sections.  He said there is repeated text appearing in the reference
flows in three places that first introduces the use of block:
  "Once all blocks of the input waveform have been processed..."
  
He reviewed new language he had added defining a block as:
  "... group of sequential waveform samples"
  
Arpad noted that Michael had added a qualifier:
  "(note that a block is assumed to contain waveform samples for at least one
   complete symbol)."
Arpad asked whether this was a new technical change.  Michael said he had added
the statement, but he was open to removing it.  Arpad said this seemed to him
like a reasonable statement, but he wasn't sure if there would ever be a case
where this restriction didn't make sense.

In the BCI messaging parameters, Michael reviewed new text he had added:
  "Note that a block is assumed to contain waveform samples for at least one
   completed UI or symbol."
Arpad said that "UI or symbol" was misleading, as it implied they might be two
different things.  The group arrived at "UI (symbol time)".

Michael noted one additional minor issue in IBIS 7.2.  He said the text does
not explicitly state a minimum allowed value for BCI_Training_UI or
BCI_Message_Interval_UI.  Therefore, it is not stated that the value 0 is
invalid.

Michael noted two locations where he had aligned the language with our
convention that "shall" is used for things that must be true and for which the
parser is able to check.  For example:
  "BCI_Message_Interval_UI shall be present if BCI_Protocol is present."

Arpad thanked Michael for starting the discussion and creating the first draft.
Arpad asked everyone to review the draft and think about possible language
clarifications.

- Michael: Motion to adjourn.
- Ambrish: Second.
- Arpad: Thank you all for joining.

New ARs:
         
- None.

-------------
Next meeting: 20 February 2024 12:00pm PT
-------------

IBIS Interconnect SPICE Wish List:

1) Simulator directives
